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CROSS-REFERENCE TO RELATED APPLICATIONS 

The present application is a continuation of pond i ng prior application No. 
08/987,346, filed on 12/09/97. entitled "Method and Architecture for Self-Provisioning 
a Rendezvous to Ensure Secure Access to Information in a Database from Multiple 
Devices^ now aUowe dU.S. Patent No. 6.065.120. which is herebv incorporated 
herein by reference . 

REFERENCE TO APPENDIXES 

Append i x A, which is o part of tho prosont d i odocuro. io a m i croficho appendix 
Goncisting of 2 shoots of microfiche having a tota l of 195 framos. Th e m i crofich e 
Append i x is a sourco codo listing of ono ombodimont of tho authont i cation and 
prov i sioning process in th e present i nvention, which is doscribed moro compiotoly 
betow^ COPYRIGHT STATEMENT 

A portion of the disclosure of this patent document contains materialr that 
includos, but is not limited to. Appendix A and Append i x B, which ic are_subject to 
copyright protection. The copyright owner has no objection to the facsimile 
reproduction by anyone of the patent document or the patent disclosure- as it 
appears in the Patent and Trademark Office patent file or records, but otherwise 
reserves all copyrights whatsoever. 

BACKGROUND OF THE INVENTION 
Field of Invention 

The invention relates to user authentication systems over data network 
systemsr and^ more particularly^ relates to a method and system for self-provisioning, 
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through a first device, a rendezvous to ensure secure access to managed 
information in a user account by other devices through the rendezvous in a data 
network, wherein the rendezvous is generally identified by a URL, the first device, 
coupled to the data network, mns a first browser under a first communication 
protocol and the other devices in the same data network run a second browser under 
a second communication protocol. 

Description of the Related Art 

The internet is a rapidly growing communication network of interconnected 
computers around the worid. Together, these millions of connected computers form 
a vast repository of hyperiinked information that Is readily accessible by any of the 
connected computers from anywhere and anytime. To provide mobility and 
portability of the Intemet, wireless computing devices were introduced and are 
capable of communicating, via wireless data networks, with the computers on the 
Internet. With the wireless data networks, people, as they travel or move about, are 
able to perform? through the wireless computing devices? exactly the same tasks 
they could do with computers on the Internet. 

The most common remote access paradigm is, as of today, the one in which a 
laptop personal computer is equipped with a wireless communication mechanism, for 
example, a wireless modem. This paradigm may remain useful for a considerable 
number of applications and users, but there has been a growing need for a mobile 
paradigm in which the Intemet can be instantly accessed by mobile devices, such as 
cellular phones and personal digital assistants. The mobile devices are generally 
designed small in size and light in weight. With increasing data processing 
capabilities in the mobile devices, more and more users start carrying the devices 
around to materialize their unproductive time into productive time. As more 
commonly seen, regular mobile phones can return calls, check voice mail or make 
users thereof available for teleconferences anywhere and anytime, but desired 
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mobile phones, not just reactive to calls but also proactive, can meld voice, data, and 
personal infomnation with manager-like functionality into a single handset that can 
effectively, through a host computer, access a myriad of public and enterprise 
infonmation services in the Internet. 

The evolution of the mobile phones or the mobile devices has been fueled by 
the demand of users for immediate access to the infonmation they are looking for. 
For example, a traveler may request an exact flight schedule when he is on his way 
to the airport, or a trader may purchase shares of stock at a certain price. The 
pertinent information from these i doas or t ransactions may include the airline and the 
flight number for the traveler^ as w el l as or the number of sharos and the-price ther e of 
of the shares being purchased by the trader. To be timely infomned, a preferable way 
is to communicate the information requests electronically into the wireless data 
network. The data network, for example, connects to a flight information server or 
stock quote server so that the desired flight information or the current stock price can 
be retrieved therefrom on demand. However, it becomes troublesome or impractical 
to key in lengthy information queries electronically into the data network through a 
mobile device that typically has a keypad with a few buttons, much less functional 
compared to a keyboard in a personal computer system. There is^ therefore^ a great 
need for a method and system for efficiently communicating desired transactions into 
a data network through which the transactions can be performed or pertinent 
information can be retrieved^ without the need to key in such information every time 
the transactions or the information afe-is_desired. In many cases^ the desired 
information in a user account, especially regarding personal matters, is preferred to 
be confidential. Thus^ there is further a need for a generic solution that provides a 
method and means for self-provisioning an account entry to a user account that has 
the proprietary information therein accessible only through the account entry. 
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SUMMARY OF THE INVENTION 

The invention pertains to improved approaches for accessing data on a data 

network bv a mobile device or a computing device. Typically, the mobile device 
(e.g.. mobile telephone with a network browser) has a limited functionality user 
interface as compared with athe full functionality user interface of the computing 
device (e.g.. personal computer). 

The invention can be Implemented in numerous ways, including as a method, 
system, apparatus, and computer readable medium. Several embodiments of the 
Invention are discussed below. 

As a method for accessing data contained in a data network system, one 

embodiment of the invention includes a^the acts of: sending a request to a server 
hosting the data to retrieve the data bv activating a key of a mobile device, the 
reguest being sent bv executing a first set of program Instructions In the mobile 
device, wherein the mobile device has a display screen and Is in communicatlonT 
over a wireless data network with the server, and further, wherein the data is 
associated with the mobile device and is also accessible bv a computing device 
executing a second set of program instructions and coupled to the server through a 
data network: receiving the data from the server via the wireless data network, the 
data presented in a first format interpretable bv the first set of program instmctions: 
and displaying the data on the display screen of the mobile device. 

As a computer readable medium including at least computer program code. 

executable in a mobile device having a display screen, for accessing data contained 
In a data network system, one embodiment of the invention includes at least: 
computer program code for sending a reguest over a wireless data network to a 
server hosting the data, the data being associated with the mobile device and 
accessible bv a computing device coupled to the server through a data network: 
computer program code for receiving the data from the server via the wireless data 
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network, the data received presented in a first format displavable by the mobile 
device and presented in a second format when accessed by the computing device: 
and computer program code for displaying the data on the display screen of the 
mobile device. 

As a computer readable medium including at least computer program code 

executable in a seryer hosting data, the data accessible by a mobile device 
executing a first browser and by a computing device executing a second browser, 
wherein the mobile device is coupled to the server through a wireless network and 
the computing device is coupled to the seryer through a data network, one 
embodiment of the invention includes at least: computer program code for receiving 
a request from the mobile device through the wireless network to access the data; 
computer program code for retrieving the data: and computer program code for 
forwarding the data to the mobile device In a first fomnat displavable on the display 
screen of the mobile device. 

Tho prosont inv e ntion has boon made i n considoration of tho abovo doscribod 
prob l ems and has particular applications to systemc of se l f authont i oation by 
authorized usors using devices that have l imited comput i ng pow e r. Co ll ular phones 
are tho typica l examp l e that has vory l i tt i o comput i ng powor and momory to caticfy 
tho powor l ong l asting and portability roquiromont, others includ e Intomet e nabl e d 
oloctronic appliances that gonorally have computing powers at a minimum as to 
roduc o tho cost thoroof for market popular i ty. Al l thoso dovicos, cons i der e d as thin 
d o vicos or c l ients horoin, i n data networks, provid e usors with portable, conveni e nt, 
and i nstant acc e ss to information be i ng sought in tho Internot; for examp l e, rotrioving 
a list of stock quotes using a mob il e phono or viowing a l ist of intorostod n e ws 
ctations on I nternet connected TVs. In both e xamploo. tho mobi l o phon e and a 
romoto control of tho TV have vory limit e d us e r interface to rocoivo inputs from 
usors. Ono of the i mportant aspects of tho present inv e ntion i s to provide a gen e r i c 
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Golution for communicating decirod idoao or transact i ons from other dovicoc with rich 
usor interface to such a thin client through a s el f provisioned account ontry. 

While adm i nistrated user auth e ntication s ystems over data networks have 
boon used e xt e nsively in areas such as administered network computers and 
electron i c comm e rce i n the Internet, th e present inv e ntion disclosing a method and 
cyctom for se l f - prov i s i oning, through a first devic e , e.g. the cellular phone or the 
remote contro l , a rendezvous to ensure secure acc e ss to a usor account by oth e r 
devices through the r e ndezvous yields unexpected resu l ts. The administrated us e r 
auth e ntication systems in comput e r n e tworks generally require each account hold e r 
to rem e mber his usomamo and associated password. If the usorname and password 
were ovor lost or forgot, the corresponding account becomes abandoned or must b e 
clar i fied by a syst e m admin i ster. The disclos e d invention, howev e r, allows a us e r to 
self prov i sion an account entry or a rendezvous w i th a s o t of crodontial informat i o FH 
wh i ch does not require tho user to writ e down or rememb e r the credentia l 
information in order to access h i s account. Furth e r, the usor is the only one who 
knows tho credentia l information created in an auth e nticated and secur e 
commun i cation ceccion for tho rendezvous, thereby the account b e comoo truly 
proprietary. Moreover through the rendezvous, the present i nvent i on for tho first time 
allows effic i ent means for communicating p e rsonalized informat i on i nto a database 
by ut i liz i ng other computers running an HTML browser w i th more familiar graphic 
usor interface whil e allowing a thin dev i ce running a micro browser to access th e 
same personal i z e d information stor e d i n the databas e . 

According to on e preferred embod i m e nt of th e present invention, a method for 
provisioning, through a thin d e vice, a rendezvous to a user account in a server to 
ensure s e cur e access to the user account by a network e d comput i ng dev i c e through 
tho r e nd e zvous having a URL, ther e by the networked comput i ng device can updat e 
managed information in the user account that i s also accessible by the thin d e v i c e , 
th e method comprises: 
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initiating a transaction signal by tho thin dovico to tho corvor; tho thin dovico 
having a client i d e ntification associat e d w i th the uoor account in the server and 
running a nnicro browser supported by a first communication protocol, whorein th e 
transact i on signal comprises the client idontification and the URL of tho rondozvous; 

e xamining a communication sess i on between tho thin dovico and tho server, 
whorein tho session examination between tho th i n device and th e server comprising: 

creating tho communication session between tho th i n device and tho son/er i f 

tho communication s e ss i on is not in ex i stence or i s not valid; 

conduct i ng mutual authont l cation between th e th i n devic e and the server; and 

generat i ng session credentia l i nformat i on for tho session such that 

subsequent transactions between tho thin device and tho server aro encrypt e d by 
the session credential information; and 

establishing user cr e dential information for tho rondozvous by the th i n d e vic e ; 

CtTTCT 

associating tho us e r crodontial i nformation w i th tho rondezvous to the user 
account i n the sender. 

Upon updating tho user cr e d e nt i al i nformation to tho rondozvous, th e 
network e d computing device w i th the correct user credent i a l informat i on can go 
through tho rond e zvous to th e usor account to edit, modify or updat e the managed 
information, e.g. a URL of a Web corvor, in tho user account with a much convenient 
information entering means, such as an HTML browser. The thin devic e can 
immodiatoly access the managed i nfonnation, such as the specified URL, to retrieve 
pertinent information thorofrom without tho need to key in tho URL that often has a 
number of a l phab e ts. 

Tho system for secure acc e ss to a us e r account in a server, through a 
rend e zvous identified gonorally by a URL, the r e ndezvous being exclus i vely 
designated to the user account, tho system compris i ng: 
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a data network comprising an oirnot supporting a first communication protoco l 

and a landnot supporting a socond communication protocol, the landnot coupled to 
tho son/or; 

a first oliont dovico, romotoly located with rospoot to tho corvor dovico and 

coupled to tho airnot us i ng a first communication protocol, having a c l ient 
identification oxc l usivoly associated with the r e ndezvous and running a first browser ; 

a second client device couplod to th e landnot using a s e cond communicat i on 

protocol and running a second brows e r; 

means for mapping th e first communicafion protocol to tho second 

communication protocol and the socond communicat i on protoco l to tho first 
communication protoco l ; the first cli e nt communicating with the server v i a tho 
communication protocol m e ans; 

moans for mapping th e first communication protocol to tho second 

communication protocol and tho second commun i cation protocol to th e first 
communication protocol; 

moans for creating an auth e nticated and cocuro communication s e ss i on 

between th e first client d e vice and tho server through tho data n e twork; the sess i on 
creating m e an s compri s ing: 

moan s for requesting tho session by tho first client device to tho server i f 

tho s e ssion is not i n e xistenc e or is not valid; 

moans for conducting mutual authentication botwoon tho first c l i e nt device 

and tho server; and 

moans for g e n e rating session cr e d e ntial information for tho session in 

creation; and 

moans, by tho first client and through tho creat e d session, for updating tho 

rendezvous with us e r cr e dential information by a first brows e r such that tho user 
account is accessible by tho s e cond client through tho rend e zvous w i th the user 
credential infonnat i on: 
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Accordingly, an important objoct of tho procont invention i s to prov i de a 
gonoric solut i on for s el f provis i oning a rondozvous to a corrosponding UGor account 
croatcd and authorizod in a server; 

Another objoct of the prosont i nvention is to provide a method and systenn for 
efficient and s e cure access to a us e r account by self provisioning a rondozvous to 
tho account as such any computer with a much oonvonient infonriation entering 
moans may update managed information in tho account; and 

Oth e r obj e cts, together with tho forgoing are attained in the exorc i se of th e 
invent i on in tho fo l lowing description and resulting in the e mbodiment illustrat e d i n 
tho accompany i ng drawings. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

These and other features, aspects, and advantages of the present invention 
will become better understood with regard to the following description, appended 
claims, and accompanying drawings where: 

Figure 1 shows a schematic representation of a data network in which the 
present invention may be practiced; 

Piwfe -Fiqures 2. a and 2.b illustrates a roprosontation reoresentations of the 
system architecture of the present invention and a layout of a corresponding user 
account in a server in communication with a mobile phone and a PC; 

Figure 3 shows a typical example of a mobile device that houses one pot i on 
portion of the linked and comp l i e d complied p rocesses disclosed in the present 
Invention; 

Figure 4 illustrates a schematic representation of a mutual authentication 
process between a mobile device and a host server to ensure subsequent 
Information transacted therebetween is secured; 

Figures 5.a and 5.b domonstrato a are flowchart representations showing the 
corresponding processes in each of the involved devices , respectiv e ly ; and 

Figures 6, 7, 8, 9 and 10 illustrate , rospoctivoly, examples of personalizing a 
user account being accessed through a self-provisioned rendezvous. 

DETAILED DESCRIPTION OF THE INVENTION 

In the following detailed description of the present invention, numerous 
specific details are set forth in order to provide a throuoh t horough understanding of 
the present invention. However, it will become obvious to those skilled in the art that 
the present invention may be practiced without these specific details. In other 
instances, well known methods, procedures, components, and circuitry have not 
been described in detail to avoid unnecessarily obscuring aspects of the present 
invention. 
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The following detailed description of the present invention in tho following are 
is presented largely in terms of procedures, steps, logic blocks, processing, and 
other symbolic representations that resemble the operations of data processing 
devices coupled to networks. These process descriptions and representations are 
the means used by those experienced or skilled in the art to most effectively convey 
the substance of their work to others skilled in the art. The present invention is a 
method and system for self-provisioning a rendezvous through a thin device to 
ensure secure access by other devices to information in a database in a data 
network. The method^ along with the system or architecture to be described in detail 
below^ is a self-consistent sequence of steps leading to a desired result. These steps 
or processes are those requiring physical manipulations of physical quantities. 
Usually, though not necessarily, these quantities may take the form of electrical 
signals capable of being stored, transferred, combined, compared, displayed and 
otherwise manipulated in a computer system or electronic computing systems. It 
proves convenient at times, principally for reasons of common usage, to refer to 
these signals as bits, values, elements, symbols, operations, messages, terms, 
numbers, or the like. It should be borne in mind that all of these similar terms are to 
be associated with the appropriate physical quantities and are merely convenient 
labels applied to these quantities. Unless specifically stated otherwise as apparent 
from the following description, it is appreciated that throughout the present 
invontion description . discussions utilizing terms such as "processing/ ©f 
"computing/ ei^"verifying/ ei^"displaying/ or the like, refer to the actions and 
processes of a computing system that manipulates and transforms data represented 
as physical quantities within the computing device's registers and memories into 
other data similariy represented as physical quantities within the computing device or 
other such device, such as storage, transmission or display devices^T 

Referring now to the drawings, in which like numerals refer to like parts 
throughout the several views. Figure 1 shows a schematic representation of a data 
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network 100 in which the present invention may be practiced. The data network 100 
comprises an airnet 102 that is generally called a_wireless network^ and a landnet 
104 that is generally a landline network, each acting as a communication medium for 
data transmission therethrough. The airnet 102, in which transmission is via the air, 
is sometimes referred to as a carrier network because each airnet is controlled and 
operated by a carrier, for example^ AT&T and GTE, each having its own 
communication scheme, such as CDPD, CDMA, GSM and TDMA^for the airnet 102. 
The landnet 104 or the Intemet, used interchangeably herein, may be the Internet, 
the-an I ntranet intranet or other private networks. Referenced by 106 is a mobile 
data device, but resembling a mobile phone therein, in communication with the airnet 
102 via an antenna 108. It is generally understood that the airnet 102 communicates 
simultaneously with a plurality of mobile computing devices of which oniy a mobile or 
cellular phone 106 is shown in the figure. Similarly, connected to the Internet 104 are 
a plurality of desktop PCs 1 1 0 and a plurality of servers 112. though only one 
representative rospootiv e ly is_shown in the figure. The PC 110, as shown in the 
figure, may be a personal compute r SPL 300 from NEC Tochnologioc Inc. and runs 
a HTML Web browser via the Intemet 104 using HTTP to access information stored 
in the web server 112 tha ^which may be a workstation ^ from SUN Microsystems 
[fiGrr It is understood to-bv those skilled in the art that the PC 1 10 can store 
accessible information therein so as to become a web server as well. Between the 
Intemet 104 and the airnet 102 there is a link server 114 performing data 
communication between the Intemet 104 and the aimet 102. The link server 1 14, 
also referred to as a_link proxy or gateway, may be a workstation or a personal 
computer and performs mapping or translation functions, for example, 
communication protocol mapping from one protocol to another, thereby a mobile 
device 106 can be in communication with any one of the servers 1 12 or the PCs 1 10t 
rocpoctivoly . 
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The communication protocol in the Intemet 104 is the well known HyperText 
Transfer Protocol e^4HTTP} and runs on TCP and controls the connection of a well 
known HyperText Markup Language Web browser, ef^HTML Web browser], to a 
Web server and the exchange of information therebetween. The communication 
protocol between the mobile device 106 and the link server 1 14 via the aimet 102 is 
Handheld Device Transport Protocol (HDTP)t or Secure Uplink Gateway Protocol 
(SUGP), which preferably runs on User Datagram Protocol (UDP) and controls the 
connection of a HDML Web browser to a link serve r and a set of commands or 
statements that specifv how information is displayed. , wh e r e HDML stands for 
Handheld Device Markup Language, rtwhich is similar to that of HTML^ and a sot of 
commands or statements that sp e cify how informat i on displayed. The specifications 
of both HDTP and HDML, being considered as the wireless network standards, are 
prov i ded at http://www,w3.orq or http://www.uplanot.com and i ncorporatod heroin by 
roforonc e available for additional details . Further^ a reference specification entitled 
"Magellan SUGP Protocol/T a HTTP specification with network security features^ is 
incorporated herein by roforonco as Append i x B U.S. Patent No. 6.065.120 . 
HDTP is a session-level protocol that resembles the-HTTP but without incurring the 
overhead thereof and is highly optimized for use in mobile devices that have 
significantly less computing power and memory. Further^ it is understood te-by_those 
skilled in the art that the UDP does not require a connection to be established 
between a client and a server before information can be exchanged, which 
eliminates the need of-for exchanging a large number of packets during a session 
creation between a client and a server. Exchanging a very small number of packets 
during a transaction is one of the desired features for a mobile device with very 
limited computing power and memory to effectively interact with a landline device. 

Referring now to Figures 2 .a and 2.b . there is depicted a representation of the 
architecture 120 of the present invention. As described above, the alrnet 102 
communicates simultaneously with a plurality of two-way mobile communication 
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devices, 122. 124 and 126, generally from a group consisting of mobile phones, two- 
"waylD'agers'and teleph'onesv jrctjch^ 
Tolocommunication Amorica. Inc.. Due to the increasing reduction in size and weight 
and high portability, most of the mobile devices, considered as thin clients, have a 
very limited computing power, typically equivalent to less than one percent of what is 
provided in a typical desktop or portable computery^ the -The memory capacity in a 
thin client is generally less than 250 kilobytes and the LCD display thereof is perhaps 
four lines high by twelve or twenty characters, the graphics capabilities thereof are 
very limited or neariy nonexistent and the general user interface is a keypad having 
far less buttons than a PC keyboard doos . Therefore^ many transactions desired by 
users through such clients are preferably predetermined or pre-entered in their user 
accounts in a host server 128 . As- as such^ the users need only to select desired 
transactions to perform or at most key in one or two letters corresponding to desired 
entries through the keypads of their cellular phones. For example, if there is a list of 
stock symbols of interest in a user account that is designated to a mobile phone, a 
user of the mobile phone will not have to key in the symbols every time he desires to 
look up fop-the price thereof currently being traded in the stock market. The list of 
stock symbols is previously entered to the user account. Evidently the most available 
and convenient means for now is to use a computing device that has powerful and 
full functional infomnation entering capabilities. A PC is a typical example of such 
computing device, the PC can be equipped with the well-known HTML browser that 
provides a rich graphic user interface and an ideal environment for the user to 
manage his personalized information in his account. 

As is well known, the Internet 104 is typically a landline network of networks 
connecting computers that aro provided utilize the HTML browser. Referenced by 
1 10 is a PC representing one of the computers that use the HTML browser running 
on HTTP to hyperlink to other computers/servers 132 or 134 to update/fetch 
information on line or simply copy files therefrom. It should be noted that "user 
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account" and "database" have been used herein sometimes interchangeably when 
"only dne rccdunt is" being' addressed rit is generally understood that a database or 
an allocation of memory, as referenced by 130 in the fioweFiaures 2.a and 2.b. 
hosts a plurality of user accounts, each designated to an authorized capacity in 
which managed or personalized information is kept. Further it is understood that the 
database 130 can be an independent storage or physically a part of the host server 
128. To access the personalized information therein from any computer on the 
Internet 104, one has to provide an account entry, namely a rendezvous, to a user 
account in the host server 128 or database 130 with a set of credential information 
such as a usemame and a password thoroof . Figure 2.b illustrates a layout of a 
typical user account assigned with a mobile phone 106. Each mobile phone is 
assigned to a device ID 140 which can be a phone number of the phone or a 
combination of an IP address and a port number, for example: 
204.163.165.132:01905; where 204.163.165.132 is the IP address^ and 01905 is the 
port number. The device ID 140 is further associated with a subscriber number (sub 
#)-142 authorized by a carrier in the link server 1 14 as part of the procedures to 
activate the phone 106. The 6ub-# subscriber number may take the form, for 
example, of 861234567-10900_pn.mobile.att.net by AT&T Wireless Service, it is a 
unique identification to the phone 106. In other words, each of the mobile devices 
122, 124 and 126 of Figure 2.a has a unique device ID that con-esponds to a user 
account in a serve r, rospoctivo l y . It may be appreciated by those skilled in the art 
that the link server 114 does not have to be a separate sovor server t o perform the 
communication protocol mapping, it can be just a part of the host server 128 and the 
protocol mapping is a-part of the f unctions the host server 128 provides. 

A corresponding account 144 in the database 130 is indexed by an account 
structure 143 comprising tho sub # subscriber number 142, user information 146, a 
usemame 148 and a password 150. Tho sub # Subscriber number 142 is received 
from the link server 1 14 as an index to the account structure 143^7-tThe user 
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information 146 comprises the account configuration and other account related 
™jnf6rrmtidn:The TiseT^^^ and the passWrTl'1 50rnameiy7the-ase^ 

information, control the authentication to enter the account 144 in the database 130, 
From the data network perspective, any computer can logon through HTTP to the 
rendezvous 152 identified by an address identifier, often a universal resource locator 
(URL) taking the form of w\ww.xyz.com. In other words, each account in a database 
is exclusively associated with a rendezvous identified by a unique URL. As shown in 
the figure, the PC 110 establishes a communication session with the rendezvous 
152 based on a given URL of the rendezvous 152. However, to access the 
associated account 144 in the database 130. the PC 110 must provide a set of a 
correct username and password to the rendezvous 152 that perfomns a verification 
thereof with the account stmcture 143. If the supplied usemame and password 
match those in the account stmcture 143, the access requested by the PC 1 10 is 
allowed. Othenwise, the-entry to the account 144 is denied. 

The PC 1 10 can update information stored in the account 144 when the 
supplied usemame and password are verified. Using the powerful and familiar HTML 
browser in the PC 1 10, a user can key in frequently requested infomnation, such as a 
list of stock symbols and a list of URLs of Web servers that provide services to the 
phone 106. An oxampio will bo provided later. _ AII the infomnation entered through 
the PC 1 10 becomes immediately available to the phone 106. 

A process named webpwd.cpp In the code listing in the appended Microfiche 
Appendix A illustrates a provisioning process between the phone 106 and the link 
sen/er 1 14 In one embodiment of the present Invention. Upon the request of the 
phone 106. the process, specifically in a subprocess called 
setNameAndPasswordStateQ, allows the phone 106 to supply a username and a 
password and then send the newly supplied credential infomnation to a second 
subprocess called submitState() that checks if the entered username and password 
are acceptable, namely the usemame and password should have a certain length 
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and contain no spaces or unrecognized characters with respect to a general rule of 
"being a usernamewd password: If the'Username and'pas^ 
the subprocess submitStateQ returns to the phone 106 with a corresponding 
message being either "You must enter a name" or "You must enter a password/V 
Otherwise, the newly entered username and password are sent to another 
subprocess called SetUserAuth() in a process called HTTPDBMSUserDB. The 
subprocess SetUserAuth() updates the usemame and password in the account 
structure 143. which immediately requires all subsequent logins to the Qcoount 
entf vrendezvous 152 with the newly supplied username and password. A 
subprocess Authenticate() examines a set of a_usemame and password supplied by 
the PC 4^ 110r 4 t and compares the usemame and password from the PC 1 10 to the 
ones in the account stmcture 143. U lf_the comparison is successful, the subprocess 
AuthentlcateO returns a AuthPass flag that allows the PC 1 10 to access the account 
in the database. Otherwise, It returns a flag that denies the admission of the PC 400 
110 to the account. 

It should be noted that the communication between the phone 106 and the 
link sevef-server_1 14 is through the airnet 102 as shown in Figures 1 and 2.a . 
Messages carrying proprietary Information travelling in the air ts -are not secure. To 
transact credential information over the open space to provision the rendezvous, a 
user must have an efficient, reliable and secured manner to conduct private 
communications with the link server. According to one embodiment of the present 
invention, an authenticated and secure session between the cellular phone 106 and 
the link server 1 14 must be in place before the cellular phone , or through which tho 
user, provisions the rendezvous to accoss his through which the user accesses 
his/her account from other computers. It is necessary to refer to an architecture of a 
mobile phone before proceeding with the detailed description of creating the 
authenticated and secure communication between a user's phone (client) and a 
server. Figure 3 is shown a block diagram of a typical GSM digital cellular phone 
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160. Each of the hardware components in the cellular phone 160 is known to those 
skilled in the art and so the hardware components are not to b e described in detail 
herein. Although the user interface of the phone 160 is not shown in detail in the 
figure, the phone 160 may be the mobile device 118 . roGombling a collular phon e , in 
of Figure 1 ^ mny hn rnfnrnnnnd th e r e to, in which roforoncod bv 116 is having a LCD 
screen 116 and 118 is a key button pad , rospoct i v e lv 118 . The screen 1 1 6 prompts a 
user what t o proceed with the keypad 1 18t with a sequence of key entries^ and 
through the phone 160, a user can interactively communicate with a server through 
the aimet, link server and the Internet. According to one embodiment of the present 
invention, compliod compiled and linked processes of the present invention are 
stored in ROM 162 as a client module 164 and support module 166. Upon activation 
of a predetermined key sequence utilizing the keypad 1 18, a physical layer 
processor or microcontroller 44&76IO initiates a session communication to the server 
using the module 164 in the ROM 162. 

To establish a secured communication between a cellular phone (a client) and 
a server, an authentication process must be conducted first to ensure that only 
interested parties are actually in the communication therebetween. According to one 
embodiment of the present invention, the code listing thereof being provided in the 
appended Microfiche Appendix, the process is complete through two rounds of 
independent authentication, one being the client authenticated by the server, 
referred to as client authentication, and the other being the server authenticated by 
the client, referred to as server authentication. Further^ each authentication is 
completed in two separate steps for a_high grade of security, which will be described 
in detail below. The success of the mutual authentication processes provisions and 
evidences that the two communicating parties possesses a valid shared secret 
encrypt key through a mutual decryption and a challenge/response mechanism. The 
mutual decryption mechanism comprises the steps of mutually recovering encrypted 
messages from two involved communicating parties. The challenge/response 
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mechanism, referred to as nonce verification, verifies a predetermined relationship 
between a sent nonce and a received derivative thereof. 

In one preferred embodiment of the present invention, the authentication 
process is conducted with three message exchanges; a Session Request (SR) 174 . 
a Session Reply {SP)jt76, and a Session Completeieo {SO 178 . Figure 4 illustrates 
a schematic representation of the authentication process. Tho client 170, 
f Representing a mobile device or the cellular phone 106 of Figure 1, the client 170 te 
conducts a transaction with the server 172, roprocontina a such as the link server 114 
of Figures 2 .a and 2.b . and initiates a SR -Session Request 174 to be sent to the 
server 172 by first creating a client proto-sesslon. A client proto-session is a session 
data structure that §ete-is_initialized when a session creation starts. The initialized 
SR -Session Request 174 comprises the following essential information: 

sessionID - an identifier identifying all requests from the client to the server; 
4fl-in the case of requesting a session creation, sessionID is always assigned 
toO; 

cipher - a two-byte number representing the choice of the encryption the client 
is currently using as there are a number of encryption schemes available in a 
communication protocol; 

devicelD - a variable up to 255-bytes. representing the device identifier or the 
client identifier^ comprisingr a phone number of the device or an IP address 
and a port number, e,g,^ 204.163.165.132:01905-; afi# 

C-nonce - a client nonce represented with a non-repeatable number, usually 
2 bytes, used for the client to conduct a following server authentication : andr 

C-nonceModified - a modified version of the client nonce, used for the server 
to conduct a nonce verification in the following client authentication. 
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Further^ the cipher in the SR -Session Request 174 includes an identifier to an 
encryption algorithm and associated parameters thereof. To be more specific, the 
first byte in the cipher represents an identifier to a combination of the encryption 
algorithm, the key size (e.g.^ 1 28-bit for the U^S^ or 40-bit for foreign countries) and 
content of a security attachment thereto; and the second byte in the cipher indicates 
the additional parameters related to the first byte._For example, value 1 in the first 
byte indicates that the encryption algorithm is block cipher RC5, the key size thereof 
Is 128 bit, a two byte check-sum therein is used as the MAC (Message 
Authentication Code), no IV (Initialization Vector for block ciphers) therefor is 
transmitted over the network, and padding bytes are added if necessary. The block 
cipher algorithm RC5 is part of the RSA's BSAFE product. It can be further 
appreciated that the identifier in the cipher may be assigned to a unique value to 
identify a non-secure session if so desired. The C-nonce is a non-repeatable number 
initially and randomly generated in the client and the modified version thereof^T C- 
nonceModifiedT Is generated from the C-nonce through an operational relationship^j 
f&f ^For example, the Exclusive-OR relationship or expressed as follows: 

C-nonceModlfied = 2-byte-number © C-nonce. 

It can be appreciated by those who are skilled in the art that there are many ways to 
get the C-nonceModified from a C-nonce, the Exclusive-OR is one of the operational 
relationships used in one embodiment of the present invention. Both C-nonce and C- 
nonceModified are encrypted using the shared secret encrypt key between the client 
170 and the server 172. The purpose of the C-nonceModified is to provide the server 
that receives the SR -Session Request w ith means for ensuring that C-nonce is 
correctly decrypted and validated by examining the C-nonce and its relationship with 
the C-nonceModified. Both should not be altered after a successful decryption of the 
C-nonce and the C-nonceModified. In other words, a Session Request S R-message 
or signal may be expressed as follows: 
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SR = {session ID, cipher, device ID, Encry[nonce, nonceModified]}; 

where Encry[ ] means that the parameters or contents In the bracket are encrypted 
accordingly. When the Session Request S R-is sent by the client to the server to 
request a session creation, both C-nonce and t C-nonceModified are encrypted 
according to the cipher the client is using at the time the Session Reauest S R-ls sent 
out. 

Upon receiving the Session Request S R-from the client 170, the server 172 
creates a server ^fote -proto- session for the client 170 with a session identifier, 
refen-ed to as session ID, to identify the session context for the session just created 
in the server 172. A server proto-session is a session entry marked as a proto status 
in a session table, which indicates that the session is not authenticated and is not 
able to conduct any transactions with the client. It is understood to those skilled in 
the art that the proto-session can be kept in the RAM of the server. If a proto-session 
already exists for that client, it is re-used. The infomnation in the received Session 
Request SR-is saved in the server proto-session. If the server 172 is satisfied with 
the fact that the client is known, namely Encry[C-nonce, C-nonceModified] in the 
received Session Request S R-are successfully decrypted with the shared secret 
encrypt key, the-step one in the client authentication process is successful and a 
corresponding session key is generated and stored with the server oroto oroto- 
session entry. It may be noted herein that many encryption schemes used in this 
invention, such as the scheme utilizing RC5, have a procedure that adds and 
validates the Message Authentication Code^ such as the check-sum, to assure that 
the encrypted message is correctly decrypted. v4heThe procedure, every time the 
decryption takes place, is used herein to examine the transaction integrity, namely to 
assure ensure t he received messages or signals are unaltered in the cause of data 
transmission. If the-step one in the client authentication is not successful, namely^ if 
Encry[C-nonce, C-nonceModified] in the received Session Request S R-are not fully 
decrypted or supported, the ^rete -proto- session is aborted and removed from the 
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proto session table, resulting in a failed session creation. What the support means 
herein is the cipher proposed or used by the client is also used by the server, for 
example^ the client uses the RC5 encryption to encrypt Encry[C-nonce, C- 
nonceModifiedli; to decrypt Encry[C-nonce, C-nonceModified], the server must be 
equipped with the same RC5 encryption capability therein. If Encry[C-nonce, C- 
nonceModlfied] can not be successfully decrypted due to other reasons such as 
transmission errors, the client must reinitiate a new session request to the server in 
order to establish a secure communication with the server. To challenge t*^step two 
oLserver authentication subsequently at the client side, a derivative of the client 
nonce or C-noncer is generated therefor. In one embodiment of the present 
invention, the derivative is created by adding a constant to the client nonce, for 
example^ derivative = C-nonce + 1. The purpose of the derivative is to provide the 
client with means for reassuring that the C-nonce is correctly decrypted by the sen/er 
and the server is the right on e i n commun i cation w i th correct server with which the 
client should be in communication . 

Right after the successful step one client authentication, the server 172 
responds to the client with a Session Reply (SP) 176 to begin a second round of 
authentication; server authentication. The SP- Session Reply 176 comprises the 
following information: 

C-SID - a one byte number indicates the sessionID originally assigned in the 
client, to be more specific^ C-SID = 0 indicates a clear. text client session, C- 
SID = 1 indicates a shared secret key encrypted session, and C-SID = 2 
indicates a session key encrypted session. In the context of the current 
description, C-SID = 1:t 

sessionID - a four-byte number representing an identification and parameters, 
such as a session encrypt key, of the session created by the server for the 
client; 
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key - a session key to be used with a mutually acceptable encryption, and to 
be used for encryption and decryption in all transactions in the session: 

derivative - a number derived from the C-nonce for the client to perform the 
subsequent server authentication; 

S-nonce - a non-repeatable number, used for the server to conduct a 
following step-two client authentication; it should be noted that S-nonce is 
generated by the server and generally different from the C-nonce by the 
client; and 

cipher - a two-byte number representing the choice of the encryption the 
server proposes after the client proposed cipher is received. 4t-Jlmay or may 
not be the same as the one used in the client. T4eTo be more specific, the 
cipher is the same as the one proposed by the client when the server 
supports the client proposed cipher, otherwise the cipher is the one currently 
used in the server. 

In other words, the Session Reply S P-can be expressed as follows^f 

SP={C-SID, Encry[sessionlD, key, S-nonce, derivative, cipher]}- 

When the client 170 receives the Session Reply SP-176 from the server 172, it 
performs the step one server authentication, which is considered successful if 
Encry[sessionlD, key, S-nonce, derivative, cipher] in the received Session Reply S R 
1 76 is decrypted successfully with the shared encrypt key. If the_step one server 
authentication fails, the client 170 discards the Session Reply S P-1 76 and a new 
session creation may be started over again. Upon the success of the step one server 
authentication, the client 170 proceeds with the step two server authentication; 
namely^ the predetermined relationship between the C-nonce and the derivative 
thereof should be held- held f or a successful step-two server authentication.T 
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C-nonce = derivative -1 

If the C-nonce derived from the Session Reply S P-1 76 is the same as the C- 
nonce originally generated by the client, the step two server authentication Is 
successful-j^hence^ the server 172 is considered authenticated, trusted from the 
viewpoint of the client, and the Session Reply S^176 is accepted as a valid 
message, which means that the client 170 then uses the session key and other 
information in the Session Reply SP-1 76 for the session being created. Only with 
after completing both Guccossful steps of the server authentication successfully, the 
client 170 marks the session as committed, which means that transactions can be 
conducted subsequently in the session, again only from the viewpoint of the client 
170. If the predetermined relationship between the client nonce and the derivative 
thereof does not hold, the step two server authentication fails and the received 
Session Reply SP-1 76 is discarded. The client 170 may abort the session creation 
process if no further Session Replies SP^are received and pass both steps of the 
server authentication process during the time period allowed for a session creation. 
To provide the server with means for reassuring the client authentication by itself 
through the client, a derivative of the S-nonce, similar to the derivative of the C- 
nonce, is generated. 

The client 170 then sends the server 172 a SC -Session Complete (SO 178 to 
complete the session creation process. The Session Complete S G-1 78 comprises 
the following information: 

SC={Encry[derivative]}; 

where the derivative is the client's response to the server nonce challenge, namely 
the result of the verification.T-the The derivative is used by the server 172 for step 
two client authentication. Further^ it is noted that the Session Complete S G-1 78 is an 
encrypted message, meaning that the client encrypts the information in the Session 
Complete S €-1 78 according to either its own cipher or the server proposed cipher, 
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Generally the client 170 encrypts the information in the Session Complete S G-178 
according to the server proposed cipher if it accepts the sen/er proposed cipher, 
otherwise, it encrypts the Session Complete S G-according to its own cipher. 

Upon rocoivinQ receipt of the Session Complete or SC 178, the server 172 
tests if the client 170 uses its own proposed cipher or the sen/er proposed cipher by 
decrypting the Session Complete S G-twice using the two ciphers if necessary. If the 
server 172 decrypts the encrypted message in the Session Complete SG-178 and 
verifies the relationship thereof with the S-nonce, the step two client authentication is 
cuGcoodod considered successful . Subsequently^ the server 172 promotes the server 
fifeto -proto- session to the active session and the session creation process is 
completed, thereby an authenticated and secure communication session is 
established between the client and the server Any transactions in the established 
communications session are now encrypted by the session key created in the server 
according to a cipher mutually agreed to by both the client and the server, thereby 
the transactions between the client and the server are tmly proprietary. A code listing 
of one embodiment of the mutual authentication is listed in tho App e ndix A LLS^ 
Patent No. 6.233.608 . 

Referring now to Figures 5.a and 5.b, each fs-illustratesd a flowchart showing 
the processes of the present invention in each involved device, respectively, in 
conjunction with Figures 6. 7, 8, 9 and 10 demonstrating examples of personalizing a 
user account being accessed through a self-provisioned rendezvous. A client 200, 
which can be a cellular phone, in Figure 5.a is one of the mobile devices 
communicating with a server 250 in Figure 5.b through a data network that is not 
nhnwn in thoGo f i Quros but similar to those illustrated in Figure 1 or Figures 2 .a and 
2.b . It should be noted that the server 250 functions as a link server and a host 
server. The functional flowcharts on the client and server sides are conjointly 
described in the following with respect to a cellular phone. Nevertheless^ it will be 
appreciated by those skilled in the art that a server, without reciting specifically a link 
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server or a host server, as referenced by 250 can perform similar functions, this 
becomes evident when the client is a landline device having direct communication to 
the Internet. 

As part of the procedures to activate a cellular phone, a user account, or 
sometimes called a_device account, is created in the server 250, the account is 
exclusively associated with the phone or client 200. In other words, each mobile 
device in the data network has its own account identified by a conresponding device 
ID and subsequently a st4b- #subscriber number in the server 250. The account for 
the client 200 is therefore created and configured at 252 according to services 
subscribed by the client 200. Meanwhile a corresponding account stmcture, similar 
to 143 in Figure 2^b, is initiated at 254. With an established account in the server 
250, the client 200 becomes one of the clients capable of communicating with any 
computers in a data network. 

When a user desires to update his personalized information in his account, he 
needs to first self-provision the rendezvous associated with his account using the 
client 200. As is shown in Figure 5.a. Tthe phone therefore requests a 
communication session to the server 250 at 202 for subsequent transactions to take 
place in an authenticated and secure communication session. From the session 
creation described above, it can be appreciated that the session creation requested 
by the client 200 includes a piece of device information assigned to the client 200. \^ 
at 20^ and 206, XThe device infonnation is_sent 204 t o the host where a 
detennination is made 206 whether the device infomnation is recognized. If the 
device infonmation is not recognized by the contacting host 250, no communication 
session can be possibly established therefor. 

Meanwhile , as shown in Figure 5.b. the host 250 receives the session 
request 258 f rom the client 200t as part of the session creation process^r-^Ihe 
device information is examined received at 260 and the session creation process 
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proceeds when the device information is verified at 262, tha^ which means that the 
device 200 has an authorized account therein. At 208 and 264 rocpootivoly, a mutual 
authentication process between the client 200 and server 250 takes place. As 
described above, the mutual authentication process comprises a client 
authentication and. a server authentication, each further comprising two rospectiv e 
steps to ensure that the communicating party is authenticated. Resulting from the 
mutual authentication process or once the session is created and authonticatod 
established at 210 and 266 of the client 200 and the sefve-seryeL250, respectively, 
a set of session credential information is generated. The session credential 
information comprises a session ID, a session key and a session cipher. The session 
ID is used to distinguish the session from other sessions that the host is creating or 
has already established with other mobile devices or clients, and the session key 
and the session cipher are to encrypt transactions between the client 200 and the 
server 250. At 212, the client 200 is -has acknowledged that there is a rendezvous 
associated with the account designated to the phono 250 client 200 . If the user 
desires to update his personalized information in the account created and authorized 
in the server 250, he may proceed at 214 with the rendezvous that is generally 
identified by a URL provided by the host 250 and is subsequently prompted for a set 
of user credential infomnation, such as a usemame and a password. At 216, the user 
credential infomnation is entered. The credential information is then sent to the host 
server 250 at 218, which includes a process of ensuring the newly supplied 
usemame and password satisfy a general rule of being a username and a password. 
The username/password ensuring process has been discussed above and the code 
listing thereof is in Appendix A U.S. Patent No. 6.233.608 . 

Meanwhile , as is shown in Figure 5.b, the host 250 is -has acknowledged that 
the client 200 is about to receive a set of new user credential information and 
expects it therefrom at 268. As soon as the new user credential infomnation *s-has 
arrived, the server 250 updates the user credential information associated with the 
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rendezvous at 270. In other words, to pass through the rendezvous to the user 
account now by other devices, the new credential infornnation must be provided. 

With the newly updated user credential information, the user can now log onto 
the rendezvous from any computer in the data network, A P C, which io not shown, 
connected to the data network (not shown) , is equipped with a familiar HTML-based 
browse r, proforably from NotGcapo Communication Corporation or Microsoft 
Corporation. As an example, it is assumed that a user has just provisioned a 
rendezvous with a usemame being "marylee" and the corresponding password being 
"123456". The user now goes to a networked PC that mns a Navigator browser-from 
NotGOopo Communication Corporation and logs onto the rendezvous based on the 
URL of the rendezvous. Figure 6 shows an interactive web page 300 received from 
the server S^after the PC made -makes t he connection to the rendezvous. It is 
understood to those skilled In the art that the page and subsequent pages can be 
constructed with HTML along with CGI script/Java applets, where the process. "CGI" 
stands for Common Gateway i ntorfaco lnterface . to receive information entered from 
a user. To update his personalized Information in his account, the user must provide 
the newly created usemame and password required at 302 and 304. respectively. It 
should be noted that the password entered is generally not echoed at 304 and 
instead indicated with an asterisk con^esponding to a -each letter entered. When the 
login icon 306 is activated, the entered usemame and password are retrieved and 
sent, through the network, to the server 2§^in which the entered usemame and 
password are verified; namely^the entered usemame and password match those 
entered and authorized by the user through the cllent-200. The user is then 
prompted with a second web page 310^ shown in Figure 7^ in which the usemame is 
displayed as referenced by 312. To categorize personalized information in the 
account, the web page 310 comprises entries to other specific service pages, such 
as a.Personal Organizer 314, Bookmarks 316 and Create a-Message 318. All these 
pages are accessible by the user to personalize his desired information therein. 
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Figure 8. for example, is a page 326 of the Personal Organizer 314 showing a 
personalized address book 320 that allows the user to edit his frequently contacted 
people's phone numbers and other Information. Figure 9 is a page 328 o f the 
Bookmarks 31 6 showing personalized bookmarks 321 t hat allows the user to 
establish a list of web sites he may frequently visit through his cellular client-2G0^r^ 
For example, StockTIPS referenced by 322 allows the user to keep a list of stock 
symbols there. With the personalized bookmarks, the user, when on the go, can 
quickly enter into the web pages having i n_his list o ^related to t he-stock symbol to 
look up forfind the prices thereof currently being traded in the stofk -stock market 
without keying in any symbols at all. As a convenient feature, tha-a_page 330 in 
Figure 10 allows the user to create an email message and be replied to at_a different 
address at-332 as decided by the user, which eliminates the inconvenience of typing 
a lengthy message through a phone keypad and reading a replied message at the 
small screen in the client-^00. 

The contents in the exemplary pages rocpoctivo l y shown in Figures 6, 7, 8, 9 
and 10 composed by HTML are accessible by an HDML browser through a server 
providing communication protocol mapping and markup language translation 
functions. Similarly^ information or messages entered on the client 200-composed by 
HDML are equally accessible by any computer equipped with an HTML browser 
through the same server in the data network. The duality of the information updating 
through two different mark-up languages provides a useful means for efficiently 
managing a personal account and substantially solves oubstantially t he problems of 
inconvenient data entry through a less functional keypad. 

The present invention has been described in sufficient detail with a certain 
degree of particularity. It is understood to those skilled in the art that the present 
disclosure of embodiments has been made by way of example only and that 
numerous changes in the arrangement and combination of parts as well as steps 
may be resorted without departing from the spirit and scope of the invention as 
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ciaimed. For example, any mobile devices equipped with a micro browser, e.g.^ 
HDML browser, may be connected, using an adapter, to the Internet directly without 
going through the aimet^r^JThe emerging Internet-enabled electronic appliances are 
also Internet-connected, all have limited computing powers and keypads but are 
capable of communicating with a server in a data network. The mutual authentication 
between such devices and the server thus becomes less complicated. The mutual 
authentication needs a process of having the client, such as a controller of the 
electronic appliance, authenticated by the server and having the server 
authenticated by the client. The process can be carried out in existing encryption 
mechanisms in HTTPS (an extended version of HTTP with built-in security), in which 
case, the link server could be replaced by a built-in capability in the device, or the 
HTTPS or the transceiver or somewhere in the connection to the Internet. The 
principles of the present invention may still be practiced in such configuration. 
Accordingly, the scope of the present invention is defined by the appended claims 
rather than the forooinQ f oregoing description of one embodiment. 
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